|
In requirements engineering, requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders.〔Requirements Engineering A good practice guide, Ramos Rowel and Kurts Alfeche, John Wiley and Sons, 1997〕 The practice is also sometimes referred to as "requirement gathering". The term elicitation is used in books and research to raise the fact that good requirements can not just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do OR NOT do (for Safety and Reliability). Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use cases, role playing and prototyping. Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process. Requirements elicitation is a part of the requirements engineering process, usually followed by analysis and specification of the requirements. Commonly used elicitation processes are the stakeholder meetings or interviews. For example, an important first meeting could be between software engineers and customers where they discuss their perspective of the requirements. ==Problems== The requirements elicitation process may appear simple: ask the customer, the users and others what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of business, and finally, how the system or product is to be used on a day-to-day basis. However, issues may arise that complicate the process. In 1992, Christel and Kang identified problems that indicate the challenges for requirements elicitation: #'Problems of scope'. The boundary of the system is ill-defined or the customers/users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives. #Problems of understanding. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be “obvious,” specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable. #Problems of volatility. The requirements change over time. The rate of change is sometimes referred to as the level of requirement volatility Requirements quality can be improved through these approaches:〔(【引用サイトリンク】url=http://www.projectauditors.com/Requirements_Quality_webinar.php )〕 #Visualization. Using tools that promote better understanding of the desired end-product such as visualization and simulation. #Consistent language. Using simple, consistent definitions for requirements described in natural language and use the business terminology that is prevalent in the enterprise. #Guidelines. Following organizational guidelines that describe the collection techniques and the types of requirements to be collected. These guidelines are then used consistently across projects. #Consistent use of templates. Producing a consistent set of models and templates to document the requirements. #Documenting dependencies. Documenting dependencies and interrelationships among requirements. #Analysis of changes. Performing root cause analysis of changes to requirements and making corrective actions. 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「Requirements elicitation」の詳細全文を読む スポンサード リンク
|